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Abstract 


This document defines new options to discover the Broadcast and 
Multicast Service (BCMCS) controller in an IP network. BCMCS is 
being developed for Third generation (3G) cellular telephone 
networks. Users of the service interact with a controller in the 
network via the Mobile Node (MN) to derive information required to 
receive Broadcast and Multicast Service. Dynamic Host Configuration 
Protocol can be used to configure the MN to access a particular 
controller. This document defines the related options and option 
codes. 
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1. Motivation 


Dynamic Host Configuration Protocol [RFC2131] and [RFC3315] can be 
used to configure various non-IP address type of parameters. These 
parameters are required for normal operation of various services that 
are offered over an IP network. 


Broadcast and Multicast Service (BCMCS) is one such service that is 
being standardized in various mobile wireless standard bodies such as 
Third Generation Partnership Project 2 (3GPP2), Open Mobile Alliance 
(OMA), and 3GPP. A description of the BCMCS as defined in 3GPP2 can 
be found in [BCMCS]. 


While DHCP already defines many options for device configuration, no 
option exists for configuring a mobile device to use BCMCS. This 
memo defines extensions for both DHCPv4 and DHCPv6 so that DHCP can 
be used to provide necessary configuration information to a mobile 
device about the BCMCS controllers. 


DHCP is being used in 3GPP2, to assist Mobile Nodes (MNs) with the 
discovery of the BCMCS Controller in a mobile operator's IP network. 
The BCMCS includes a controller component that is responsible for 
managing the service via interaction with the MN and other network 
entities. In this document, we will call this a BCMCS controller. 
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An overview of the 3GPP2 BCMCS architecture is given in the next 
section. It provides enough information to understand the basics of 
the 3GPP2 BCMCS operation. Readers are encouraged to find a more 
detailed description in [BCMCS]. 


As described in [BCMCS], the MNs are required to know the IPv4 or the 
IPv6 address of the BCMCS controller entity so that they can download 
all the necessary information about a desired broadcast and/or a 
multicast program. In a roaming environment, static configuration of 
the BCMCS controller’s IP address becomes unrealistic. Therefore, 
DHCP is considered to be a method to dynamically configure the MNs 
with the IP address or the fully qualified domain name (FQDN) of the 
BCMCS controller in the 3G cellular telephone networks. 


In order to allow the MNs to discover the BCMCS controllers, the MNs 
request the appropriate option codes from the DHCP server. The DHCP 
servers need to return the corresponding configuration options that 
carry either BCMCS controller’s IP address or FQDN based on 
configuration. This document defines the necessary options and 
option codes. 


2. Overview of the 3GPP2 BCMCS Network 


The Broadcast and Multicast Service architecture in a 3G cellular 
telephone network such as 3GPP2 has the following model: 


+------------ + +-------- + 
BCMCS 
Controller DHCP 
| | | Server | 
+------------ + +-------- + 
Control | 
Info 
| 
V 
+----+ +------------ + +------------ + 
| | | | | | 
MN/| bearer Radio BCMCS 
User | <------- Access Be Content 
| | | Network | | Server | 
+----+ +------------ + +------------ + 


Note that this figure is shown here for a basic understanding of how 
Broadcast and Multicast Service works in a 3G cellular telephone 
network. The network elements except MN/user and the DHCP server are 
not relevant to the text in this document. 
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The MN interacts with the BCMCS Controller to request broadcast/ 
multicast program information from the network (e.g., scheduled time, 


multicast IP address, port numbers). The MN may also be 
authenticated by the BCMCS Controller while downloading the relevant 
program-security-related information (such as encryption key). These 


interactions may happen via HTTP and XML as defined in [BCMCS]. 

There may be more than one BCMCS controller in the network. The MN 
should discover the appropriate BCMCS controller to request the 
relevant program information. For details of Broadcast and Multicast 
Service operation in 3GPP2, see [BCMCS]. 


3. Terminology 
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


4. Broadcast and Multicast Service Controller Options 


This section defines the configuration option for the BCMCS 
controller of the Broadcast and Multicast Service. 


4.1. Broadcast and Multicast Service Controller Domain Name List for 
DHCPv4 


The general format of the BCMCS Controller Domain list option for 
DHCPv4 is as follows: 


Code Len FQDN(s) of BCMCS Controller 
+----- +----- +----- +----- +----- +----- +----- +-- 
| 88 | a | s1 | s2 | s3 | s4 | s5 | 
+----- +----- +----- +----- +----- +----- +----- +-- 


The option MAY contain multiple domain names, but these domain names 
SHOULD be used to construct Service Record (SRV) lookups as specified 
in [BCMCS], rather than querying for different A records. The client 
can try any or ALL of the domain names to construct the SRV lookups. 
The list of domain names MAY contain the domain name of the access 
provider and its partner networks that also offer Broadcast and 
Multicast Service. 


As an example, the access provider may have one or more partners or 
resellers often termed as MVNOs (Mobile Virtual Network Operators) 
for Broadcast and Multicast Service. In this case, the access 
provider should be able to use the same DHCP option to send multiple 
of those domain names (MVNOs). To illustrate this further, let’s 
assume that the access provider (operator) has a reseller agreement 
with two MVNOs: mvnol and mvno2. Therefore, the Broadcast and 
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Multicast Service Controller Domain Name list for the DHCPv4 option 
will contain three domain names: operator.com, mvnol.com, and 
mvno2.com. Upon receiving this option, the BCMCS client may choose 
to use one of the domain names to fetch the appropriate BCMCS 
controller address (based on user’s preference or configuration). If 
no preferred domain name is found in the received list, the client 
should use a default setting, e.g., use the first one in the list. 


If the length of the domain list exceeds the maximum permissible 
length within a single option (254 octets), then the domain list MUST 
be represented in the DHCPv4 message as specified in [RFC3396]. An 
example case when two controller domain names, example.com and 
example.net, are returned will be: 


$a pene Pe eS Pe Se a ee Se ee ee SS aS Se ee Pe et 
| 88 | 26 | 7 | re’ | rar rar | 'm | 'p' | HIR] ret | 3 | 
E A e S T E aa: ES ints E Gare E E A E E EE 
Pet R Le Ses fees Stas Se = Se SPS See eS N L L 
|e |o | 'm | 0 | 7 | re! | righ | ra’ | 'm | Aa rue | 
pot SepeccSe tes Ss fo Sse Sse e pe eoe poses Ses Seep ese tees 
E Sie e r E E lau SE ite E 3 
e | 3 | 'n' | re’ | Pee 0 | 
SSeS Pee ee Se ee ee ee 
4.2. Broadcast and Multicast Service Controller Domain Name List Option 
for DHCPv6 


The semantics and content of the DHCPv6 encoding of this option are 
exactly the same as the encoding described in the previous section, 
other than necessary differences between the way options are encoded 
in DHCPv4 and DHCPv6. 


Specifically, the DHCPv6 option for the BCMCS Control Server Domain 
Names has the following format: 


0 1 2 3 
0123456789012345678°90123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_BCMCS_SERVER_D | option-length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| BCMCS Control Server Domain Name List 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
option-code: OPTION_BCMCS_SERVER_D (33). 


option-length: Length of the ’BCMCS Control Server Domain Name List’ 
field in octets; variable. 
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Identical format as in Section 


4.3. Broadcast and Multicast Service Controller IPv4 Address Option for 
DHCPv4 


The Length byte ( 
indicating BCMCS controller IPv4 addresses. 


MUST be listed in order of preference. 
the length MUST be a multiple of 4. 


Len) is followed by a list of IPv4 addresses 
The BCMCS controllers 


encoding has the following format: 


Its minimum length is 4, and 
The DHCPv4 option for this 


Code Len Address 1 Address 2 
+----- +----- +----- +----- +----- +----- +----- +-- 
| 89 | n | at | a2 |a3 | a4 | al | 
+----- +----- +----- +----- +----- +----- +----- +-- 
4.4. Broadcast and Multicast Service Controller IPv6 Address Option for 
DHCPv6 


This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of 
the BCMCS Controller in an operator’s network. 


0) 


1 2 


3 


012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
OPTION_BCMCS_SERVER_A | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


BCMCS Control server-1 address (IPv6 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


BCMCS Control server-2 address (IPv6 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


option- 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


code: OPTION_BCMCS_SERVER_A (34). 


option-length: Length of the ’BCMCS Control 
field in octets; 


Chowdhury, 


et al. 


variable. 


Standards Track 


option-length 
+-+-+-+-+-+-+ 


address) 


+-+-+-+-+-+-+ 


address) 


+-+-+-+-+-+-+ 


+-+-+-+-+-+-+ 


| 
+ 
| 
| 
| 
| 


+-+-+-4+- 
+-+-+-+-+ 


+-+-+-+-+ 


+-+-+-+-+ 


Server IPv6 address’ 
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4.5. Consideration for Client Operation 


For DHCPv4, the client MAY request either or both of the BCMCS 
Controller Domain Name List and the IPv4 Address options in the 
Parameter Request List option (code 55) as defined in [RFC2132]. 


For DHCPv6, the client MAY request either or both of the BCMCS 
Controller Domain Name List and the IPv6 Address options in the 
Options Request Option (ORO) as described in [RFC3315]. 


If the client receives both the BCMCS Controller Domain Name List and 
IPv6 or IPv4 Address options, it SHOULD use the Domain Name List 
option. In this case, the client SHOULD NOT use the BCMCS Controller 
IPv6 or IPv4 Address option unless the server(s) in the BCMCS 
Controller Domain Name List cannot be resolved or reached. 


4.6. Consideration for Server Operation 


A server MAY send a client either the BCMCS Controller Domain Name 
List Option or the BCMCS Controller IPv6 Address/IPv4 Address options 
if the server is configured to do so. 


If a client requests both the options and the server is configured 
with both types of information, the server MAY send the client only 
one of the options if it is configured to do so. In this case, the 
server SHOULD send the BCMCS Controller Domain Name List option. 


A server configured with the BCMCS Controller IPv6 or IPv4 Address 
information MUST send a client the BCMCS Controller IPv6 or IPv4 
Address option if that client requested only the BCMCS Controller 
IPv6 or IPv4 Address option and not the BCMCS Controller Domain Name 
List option in the ORO or Parameter Request List option. 


If a client requests for the BCMCS Controller IPv6 or IPv4 Address 
option and the server is configured only with the domain name(s), the 
server MUST return the Domain Name List and vice versa. 


The domain names MUST be concatenated and encoded using the technique 


described in Section 3.3 of "Domain Names - Implementation and 
Specification" [RFC1035]. DNS name compression MUST NOT be used. 
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3% 


The following table summarizes the server’s response: 


Client sends in ORO/ 


Parameter Request List Domain Name List IPv6/IPv4 Address 
Neither option SHOULD MAY 
Domain Name List MUST MAY 
IPv6/IPv4 Address MAY MUST 
Both options SHOULD MAY 


Security Considerations 


This document does not introduce any new security concerns beyond 
those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] 
specifications. In the absence of message integrity protection for 
these options, an attacker could modify the option values to divert 
requests for broadcast service. 


IANA Considerations 


The following option codes for Broadcast and Multicast Service 
Controller option have been assigned by IANA: 


1. The BCMCS Controller Domain Name list (Section 4.1) has been 
assigned a value of 88 from the DHCPv4 option space. 


2. The BCMCS Controller Domain Name list (Section 4.2) has been 
assigned a value of 33 from the DHCPv6 option space, and a name of 
OPTION_BCMCS_SERVER_D. 


3. The BCMCS Controller IPv4 Address option (Section 4.3) has been 
assigned a value of 89 from the DHCPv4 option space. 


4. The BCMCS Controller IPv6 Address option (Section 4.4) has been 
assigned a value of 34 from the DHCPv6 option space, and a name of 
OPTION_BCMCS_SERVER_A. 
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